[git-annex.git] /

[[!comment format=mdwn
 username="joey"
 subject="""comment 6"""
 date="2021-07-12T15:42:52Z"
 content="""
Almost anything can be argued to reflect the nature of some repo in some way.
That's not a useful criteria.

And the same could be argued about many git configs, and of course they
cannot be set globally, and noone is bothered much by this, because we can
all arrange for git configs to be set after cloning a repo.

I don't know what the right criteria is, but I do know I don't want to
force users to have to worry about overriding every possible config locally
because it's been set globally. git-annex should not behave in a near infinity
of different ways in clones of different repos, because that would make its
starting behavior impossible to understand.

So the more there are requests for more global configs, the more it seems
like adding any global configs, without a strong criteria, is not a good
idea.

Some global configs that do make sense are numcopies and required copies
settings, because those values need to be coordinated globally to make sure
enough copies are preserved. Similarly, preferred content because one
repo needs to know what is preferred content of another repo. And I think
annex.securehashesonly makes sense as a global, to avoid adding files
with insecure hashes that would then not be accessible in repos with
that config set. annex.largefiles mostly makes sense because .gitattributes
has a whitespace problem which it avoids, and it's similar to using
.gitattributes (although not identical). It feels on the edge.

annex.synccontent etc are explicitly about changing the default behavior
of a command. At the moment I feel like they were a bad idea.
"""]]